1. Technical Field
The present invention relates generally to an improved data processing system and, in particular, to a method and system for authenticating a user of a data processing system before providing access to the data processing system to the user.
2. Description of Related Art
A certificate is a digital document that vouches for the identity and key ownership of an individual, a computer system, a specific server running on that system, or an organization. For example, a user""s certificate verifies that the user owns a particular public key.
Certificates are issued by certificate authorities. These authorities are responsible for verifying the identity and key ownership of the individual before issuing the certificate.
An identity certificate is a digitally signed statement from one entity, saying that the public key of some other-entity has some particular value.
Public keys are numbers associated with a particular entity, and are intended to be known to everyone who needs to have trusted interactions with that entity.
An entity is a person, organization, program, computer, business, bank, etc.
If some data is digitally signed, it has been stored with the xe2x80x9cidentityxe2x80x9d of an entity and a signature that proves that entity knows about the data.
A signature is computed from some data and the private key of an entity.
Private keys are numbers that are supposed to be known only to a particular entity, i.e. kept secret. In a typical public key cryptographic system, a private key corresponds to exactly one public key.
Certificates rely on public key cryptographic systems in which (a) private and public keys are paired, (b) private keys are used to sign, and (c) public keys are used to verify signatures.
A certificate authority (CA) is an entity (e.g., a business) that is trusted to sign (issue) certificates for other people (entities). It usually has some kind of legal responsibilities for its vouching of the binding between a public key and its owner that allow one to trust the entity that signed a certificate. There are many such certificate authorities, such as VeriSign, Entrust, etc.
Probably the most widely visible application of certificates today is in Web browsers, such as Netscape Navigator that support the SSL protocol. SSL (Secure Socket Layer) is a security protocol that provides privacy and authentication in network traffic. Browsers can only use this protocol with Web servers that support it.
Other technologies that rely on certificates include: various secure e-mail standards, such as Secure/Multipurpose Internet Mail Extensions (S/MIME); e-commerce protocols, such as Secure Electronic Transaction (SET); and various code-signing schemes, such as Microsoft AuthentiCode and signed Java Archives (JAR files).
There are two basic techniques used to get certificates: (1) make one oneself using the proper software, or (2) ask someone else, such as a certificate authority, to issue one. There are two main inputs to the certificate creation process. The first input is a pair of matched public and private keys generated using some special software. Only the public key is ever shown to anyone else. The private key is used to sign data; if someone improperly knows a private key, they can forge legal documents attributed to a third party. The second input is information about the entity being certified, such as an individual. This normally includes information such as a name and organization address. If a certificate authority issues a certificate, one will normally need to provide proof of identity.
If a certificate authority issues a certificate for an individual, the individual must provide a public key and some information about himself. A tool, such as Netscape Navigator 3.0, may digitally sign this information and send it to the certificate authority. The certificate authority might be a company like VeriSign that provides trusted third-party certificate authority services. The certificate authority will then generate the certificate and return it. The certificate may contain other information, such as dates during which the certificate is valid and a serial number. One part of the value provided by a certificate authority is to serve as a neutral and trusted introduction service, based in part on their verification requirements, which are openly published in their Certification Service Practices (CSP).
The X.509 standard is one of many standards that defines what information can go into a certificate and describes the data format of that information.
The xe2x80x9cversionxe2x80x9d field indicates the X.509 version of the certificate format (1, 2, or 3), with provision for future versions of the standard. This identifies which version of the X.509 standard applies to this certificate, which affects what information can be specified in it. Thus far, three versions are defined. Version 1 of the X.509 standard for public key certificates was ratified in 1988. The version 2 standard, ratified in 1993, contained only minor enhancements to the version 1 standard. Version 3, defined in 1996, allows for flexible extensions to certificates in which certificates can be xe2x80x9cextendedxe2x80x9d in a standardized and generic fashion to include additional information. In addition to the traditional fields in public key certificates (i.e. those defined in versions 1 and 2 of X.509), version 3 comprises extensions referred to as xe2x80x9cstandard extensionsxe2x80x9d. The term xe2x80x9cstandard extensionsxe2x80x9d refers to the fact that the version 3 X.509 standard defines some broadly applicable extensions to the version 2 certificate. However, certificates are not constrained to only the standard extensions and anyone can register an extension with the appropriate authorities (e.g., ISO). The extension mechanism itself is completely generic.
The xe2x80x9cserial numberxe2x80x9d field specifies the unique, numerical identifier of the certificate in the domain of all public key certificates issued by a particular certificate authority (CA) in order to distinguish one certificate from another. When a certificate is revoked, it is actually the certificate serial number that is posted in a certificate revocation list signed by the certificate authority since posting the entire certificate would be wasteful and completely unnecessary. It is for this reason that the serial number for each certificate in the domain must be unique.
The xe2x80x9csignature algorithmxe2x80x9d field identifies the algorithm used by the certificate authority to sign the certificate. The algorithm identifier, which is a number registered with an internationally-recognized standards organization (e.g., ISO), specifies both the public-key algorithm and the hashing algorithm used by the certificate authority to sign certificates.
The xe2x80x9cissuer namexe2x80x9d field specifies the X.500 Distinguished Name (DN) of the certificate authority that issued the certificate. For example, the Distinguished Name xe2x80x9cc=US, o=ACME Corporationxe2x80x9d might be used as the Distinguished Name for the certificate authority issuing certificates to the employees of the ACME Corporation in the United States. In some cases, such as root or top-level certificate authority certificates, the issuer signs its own certificates.
The xe2x80x9cvalidity periodxe2x80x9d field specifies the dates and times for the start date and the expiration date of the certificate. Every time a certificate is used, the software should examine the certificate to ensure it is still within its validity period. Each certificate is valid only for a limited amount of time, but this period can be as short as a few seconds or almost as long as a century. The validity period depends on a number of factors, such as the strength of the private key used to sign the certificate or the amount one is willing to pay for a certificate.
The xe2x80x9csubject namexe2x80x9d field specifies the X.500 Distinguished Name of the entity holding the private key corresponding to the public key identified in the certificate; for example, the Distinguished Name xe2x80x9cc=US, o=ACME Corporation, cn=John M. Smithxe2x80x9d might be the Distinguished Name for employee John M. Smith of the ACME corporation, where xe2x80x9ccnxe2x80x9d stands for xe2x80x9ccommon namexe2x80x9d, xe2x80x9coxe2x80x9d is xe2x80x9corganizationxe2x80x9d, and xe2x80x9ccxe2x80x9d is xe2x80x9ccountryxe2x80x9d.
The xe2x80x9cpublic keyxe2x80x9d field is the public key of the entity being named or identified by the certificate.
The xe2x80x9csubject public key informationxe2x80x9d field identifies two important pieces of information: a) the value of the public key owned by the subject, and b) the algorithm identifier specifying the algorithm with which the public key is to be used. The algorithm identifier specifies both the public-key algorithm and the hashing algorithm.
The xe2x80x9cissuer unique identifierxe2x80x9d field was added to the X.509 certificate definition as part of the version 2 standard. The field, which is optional, provides a location to specify a bit string to uniquely identify the issuer X.500 name, in the event that the same X.500 name has been assigned to more than one certificate authority over time.
The xe2x80x9csubject unique identifierxe2x80x9d field was added to the X.509 certificate definition as part of the version 2 standard. The field, which is optional, provides a location to specify a bit string to uniquely identify the subject X.500 name, in the event that the same X.500 name has been assigned to more than one subject over time (e.g., one John M. Smith leaves ACME Corporation and a second John M. Smith joins ACME Corporation two months later). This field is not used by most, certificate authorities for various reasons primarily because there are more convenient ways to uniquely identify a subject. Specifically, most certificate authorities use the serial Number attribute. Such a scheme fits well within an organization""s administrative and directory management procedures because employees require a unique identifier in their X.500 common names anyway (e.g., to handle the case where there are two John M. Smith""s in the organization at the same time).
X.509 Version 1 has been-available since 1988, is widely deployed, and is the most generic.
X.509 Version 2 introduced the concept of subject and issuer unique identifiers to handle the possibility of reuse of subject and/or issuer names over time. Most certificate profile documents strongly recommend that names not be reused, and that certificates should not make use of unique identifiers. Version 2 certificates are not widely used.
X.509 Version 3 is the most recent (1996) and supports the notion of extensions, whereby anyone can define an extension and include it in the certificate. Some common extensions in use today are: KeyUsage, which limits the use of the keys for particular purposes such as xe2x80x9csigning-onlyxe2x80x9d; and AltNames, which allows other identities to also be associated with this public key, e.g., DNS names, e-mail addresses, IP addresses. Extensions can be marked critical to indicate that the extension should be checked and enforced/used. So, for example, if a certificate has the KeyUsage extension marked critical and set to xe2x80x9ckeyCertSignxe2x80x9d then if this certificate is presented during SSL Communication, it should be rejected, as the certificate extension indicates that the associated private key should only be used for signing certificates and not for SSL.
All the data in a certificate is encoded using two related standards called ASN.1/DER. Abstract Syntax Notation 1 describes data. The Definite Encoding Rules describe a single way to store and transfer that data.
The keys used to interact with various parties need to be hung in a xe2x80x9ckey chain.xe2x80x9d In the physical world, a key ring holds keys, and a wallet hold multiple identification and credit cards. In the digital world, a directory service provides storage for digital keys and certificates. The X.500 and LDAP (Lightweight Directory Access Protocol) standards are two main contenders for directory services. Each entry in the directory service is globally and uniquely identified by a Distinguished Name. For example, John M. Smith, who belongs in the Executive Office department at Acme Corporation, might have the following Distinguished Name: xe2x80x9ccn=John M. Smith, ou=Executive Office, o=ACME Corporation, c=USxe2x80x9d, where xe2x80x9ccnxe2x80x9d stands for xe2x80x9ccommon namexe2x80x9d, xe2x80x9couxe2x80x9d is xe2x80x9corganizational unitxe2x80x9d, xe2x80x9coxe2x80x9d is xe2x80x9corganizationxe2x80x9d, and xe2x80x9ccxe2x80x9d is xe2x80x9ccountryxe2x80x9d.
Second-generation directory services store entries in proprietary file formats, hash, B-tree, or Relational Database Management System. Although RDBMS is not necessarily optimized for X.500 Distinguished Names, the maturity, scalability and additional utilities in RDBMS make it an attractive alternative as a directory service repository. X.509v3 certificates and public keys can also be stored and protected in an X.500- or LDAP-based directory service. If a user""s secret key is compromised, the certificate associated with the public key must be revoked and added to the appropriate certificate authority""s Certificate Revocation List (CRL). There is a delicate balance between the frequency of CRL updatexe2x80x94especially if there are several CRL replicasxe2x80x94and minimizing the amount of damage caused by the compromised key. Real-time CRL updates shrink the window of vulnerability, but in a mass market they require more overhead than a batched nightly update approach.
With reference now to FIGS. 15A-15G, simplified block diagrams-depict a prior art method of authenticating a customer to a financial institution through the use of certificates. FIG. 15A shows that the prior art method required three parties to be involved in a financial transaction. Customer 1501 may be a consumer of financial services supplied by financial institution 1502, which may be a traditional financial institution or a credit card company that supplies various financial services through well known transactions, such as checking account transactions, credit card transactions, etc.
Before performing a financial transaction with financial institution 1502, customer 1501 has been instructed to obtain a digital certificate. Financial institution 1502 may accept digital certificates issued by a variety of authorized, trusted third parties. One of these third parties may be represented by trusted third party 1503. FIG. 15B shows that customer 1501 transmits an appropriate message to trusted third party 1503 requesting the issuance of a digital certificate. Trusted third party 1503 has access to a database comprising information on many individuals. Customer 1501 must provide enough identifying information to trusted third party 1503 so that trusted third party 1503 may authenticate the identity of customer 1501.
FIG. 15C shows that trusted third party 1503 issues a certificate to customer 1501 upon authentication of the identity of customer 1501.
FIG. 15D shows customer 1501 presenting the previously issued certificate to financial institution 1502 while requesting financial services from financial institution 1502 in an electronic manner.
FIG. 15E shows that financial institution 1502 must authenticate the presented certificate by transmitting an authentication request to trusted third party 1503. In so doing, financial institution 1502 may also be required to supply a previously issued certificate to trusted third party 1503 so that trusted third party 1503 may authenticate the origination of the authentication request. In other words, trusted third party 1503 may also authenticate the identity of the party representing itself as financial institution 1502.
FIG. 15F shows trusted third party 1503 responding to the authentication request by transmitting the appropriate failure or success message to financial institution 1502 that does or does not authenticate the identity of customer 1501.
FIG. 15G shows a situation in which financial institution 1502 has authenticated the identity of customer 1501 and has proceeded to perform financial transactions with customer 1501.
At each transmission step shown in FIGS. 15A-15G, the communication may be performed according to appropriate secure communication protocols. In one respect, trusted third party 1503 acts as a registration authority for customer 1501 by issuing certificates to authenticated persons. In another capacity, trusted third party 1503 acts as a certification authority for financial institution 1502 by validating presented certificates. Financial institution 1502 is the central figure in this method of authenticating the identity of customer 1501. Financial institution 1502 guides customer 1501 in its selection of an authorized trusted third party. Financial institution 1502 is also attempting to provide financial services to customer 1501. In directing customer 1501 to interact with trusted third party 1503, financial institution 1502 complicates the provision of services to customer 1501. Customer 1501 may find it difficult or confusing to interact with a third party outside of financial institution 1502, and the customer may be physically and technologically inconvenienced in so doing.
In addition to the inconvenience to the customer of interacting with the third party, the maintenance of valid certificates may also create many difficulties. As described above, each certificate has a unique identifier called a Distinguished Name. Certificates are managed, e.g., issued and revoked, by a certificate authority, and certificate management can represent significant costs to the application.
Certificates are revoked when security has been compromised, such as a loss, theft, modification, unauthorized disclosure, or a compromise of the private key of the certificate. Certificates are permanently invalidated and can not be xe2x80x98unrevokedxe2x80x99, resumed, reinstated, or reactivated later. A user whose certificate has been revoked must request that a new certificate be issued with additional costs to the application and/or user.
At other times, however, the application may need to temporarily disable a user""s access to his account data, or a user may wish to prevent access to his account data for some period of time. A problem exists with current certificate schemes as there is no way to temporarily revoke access to a user""s account data. Since there is no suspend/resume actions associated with certificates, the current solution for suspending a certificate is to revoke it. This renders the certificate permanently invalid, and in order to resume use of the certificate, a new certificate must be issued using time and resources.
The present invention provides a method and system for certificating and authenticating an identity of a customer of a financial institution using digital certificates. The customer and the financial institution communicate via a communications medium. The financial institution receives a digital registration request from the customer and verifies the identity of the customer by reconciling identification data in the digital registration request with identification data in a customer data structure at the financial institution. Responsive to verifying the identity of the customer, the financial institution generates a digital certificate and sends the digital certificate to the customer. When the customer desires access to an on-line application at the financial institution, the customer sends the previously issued digital certificate to the financial institution via the communications link. The financial institution authenticates the digital certificate and grants on-line application access based upon the authenticated digital certificate. The digital certificate may be suspended without being revoked by associatively storing certificate-state information with the distinguished name of the certificate owner, thereby providing a mechanism for suspending and resuming access privileges of the customer.